Cream of the Crop 12

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 12 / Cream of the Crop 12 (Part II) / Cream of the Crop 12 (Part II).iso / BBS / NEFD233.ZIP / NEF.DOC < prev next >

Wrap

Text File | 1996-03-13 | 113.9 KB | 2,919 lines

************************************************************** * * * * * ** ** ******* ******* * * *** ** ** * ** * * * **** ** ** * ** * * * ** **** **** **** * * ** *** ** * ** * * * ** ** ** * ** * * ** ** ******* **** * * * * * * Version 2.33 * * * * File Distribution for "BinkleyTerm Style" Systems * * * * * ************************************************************** * * * (C) Copyright 1991-1996 by Alberto Pasquale * * * * A L L R I G H T S R E S E R V E D * * * ************************************************************** "BinkleyTerm" is trademark of Bit Bucket Software, Co. NEF 2.33 User's Manual, by Alberto Pasquale INTRODUCTION -> For licensing information, please see License.Doc. Thanks for evaluating NEF: a "New Echo Files" distribution system. Main Features - It works on systems with a Binkley Style outbound and *.MSG or Squish message base. - File Import/Forward/Hatch via the standard .TIC system, initially implemented by Tick. - File "Areafix", to automatically link/unlink file areas via netmail messages. Wildcards can be used to make multiple link/unlink requests easier. - Support for "FileBone.Na style" files. - Automatic forwarding of requests for missing areas to the uplinks. - Fast Squish netmail scan. - Flexible file announcements via echo or netmail messages. Wildcards in file area tags allow easy configuration of multiple announcement areas for different groups of file areas. - Full multitasking support. File sharing problems are handled wherever necessary. - Full 4D operation; no direct support for ancient pointnet addressing method. However points addressed via pointnet can obviously be seen with their pointnet adress. - Different outbounds for different domains are supported the same way as in Squish, via zone mapping. - Very flexible MultiAka support. You can use different addresses in different areas, different addresses for different downlinks in the same area, etc. - Outbound analysis and report to message areas and/or file. - "Passthru" Area support. - Long Description ("LDESC" keyword) support. - Multiple "Desc" support. - Multi-line description support for Files.Bbs. - EchoToss.Log support. - Automatic creation of new areas from authorized uplinks. - Automatic linking of specified downlinks to selected new areas when they are automatically created. - Check on imported description strings, to avoid trojan horses using certain control characters. - Clean and compact link configuration file. - Easy addition (on area TAG basis) of text strings at the head of imported descriptions, to allow inclusion of flags and download counters in selected areas. - Easy partial/total area split/merge: you can forward certain files to a new area TAG. - Support for Maximus 3.xx FileBase: when the file areas are modified the filebase is internally updated (no need for external FB/FBP). The additional UniFiles.Idx (with no duplicates) created by QFB (my FB/FBP substitute) is also maintained. - Automatic addition of new areas to the Maximus 3.xx configuration. - Support for Squish configuration file, to get the information about path, type and primary address of message areas directly from it. - (OS/2) Support for "Feature DLLs": developers can find the necessary Header file and an example C source included in the NEF package (Nefeat.H, Feature.C, Feature.Dll). CREDITS "BinkleyTerm" is a trademark of Bit Bucket Software Co. This program uses the Squish "MsgAPI" code, Copyright 1991-1994 by Lanius Corporation. "Squish" and "Maximus" are trademarks of Lanius Corporation. "Tick" is Copyright by Barry Geller The archivers referred-to throughout this documentation are Copyright and/or trademarks of the respective owners. OVERALL OPERATION When invoked, first of all NEF looks into the netmail area(s) for netmail messages to the Link Robot (Areafix like) and executes the commands required; then it looks for new .TIC files in the netfile area(s) and forwards them. The ingoing files are moved to their destination directory and the description is appended to the files.bbs. A careful check is operated on the text of the description, to avoid trojan horses that use special control characters. Existing old descriptions for the ingoing files are deleted. If the Replaces field is present in the ingoing .TIC (and the function is not disabled in NEF.CFG), the pertinent file is erased and its description removed from the files.bbs. The forwarded TICs will have a new Path line with UTC time of forward and updated SeenBys; Points are not included in the SeenBys of TICs addressed to other links, to avoid unnecessarily huge lists of SeenBys. The .BSY support avoids conflicts in the outbound, while possible conflicts in the access to files.bbs are minimized by waiting several seconds before giving up. Finally, NEF writes the announcements of the received files; each message is limited (before splitting) to the maximum size specified with the "MsgSize" statement (default is 12KB to avoid problems with old mail processors). Conflicts on the message base are handled by the Squish MsgAPI. When the Maximus FileBase support is enabled, a mutual exclusive semaphore flag "FileBase.Bsy" is used to avoid concurrent access and modification of the filebase by other ApWorks programs. There is no need to delete this flag if it remains after a power failure or abnormal termination (ApWorks programs are smart enough to realize whether the flag is really in use or not). From Address Selection The algorythm to choose the "From" address for the TIC files is: If an aka ovverride is present in the "FileArea" definition then use FileArea aka override else if an aka override is present in the "FileLink" definition then use FileLink aka override else if the destination zone matches an "Address" statement then use the zone-matching address else use the primary (first) "Address" statement. Description Handling The TIC files can contain "Desc" and "LDesc" lines. Usually the description contained in "Desc" line(s) is short and unformatted, while that carried by the "LDesc" lines is long, multi-line and formatted. For the announcements, the longest one is selected. For the Files.Bbs: if MultiLineDesc support is enabled, the longest description is used, otherwise the "Desc" one. INSTALLATION 1) There are 2 versions of NEF: OS/2 and DOS/32, distributed in different archives. The main program is always named NEF.EXE: please make sure you have the correct version. 2) Edit your Nef.Cfg. You can find useful examples in the NEF_*.Cfg files and detailed information in the "CFG REFERENCE" section of this documentation. 3) Edit your batch file in order to call NEF whenever you would like to test for the presence of .TIC files in your inbounds and process them. If you do not pass a different pathname as a command line parameter, Nef.Cfg must reside in the current directory. 4) (OS/2): Make sure you have the MSGAPI32.DLL in a directory contained in your LIBPATH and the PmHatch.Exe program in your PATH. MSGAPI32.DLL can be found in the Squish 1.11 archive. (DOS): Make sure you have the DOS4GW.EXE Dos extender (from Rational System Inc.) in your path. The DOS4GW extender requires an XMS or DPMI memory driver installed in your config.sys: e.g. HIMEM.SYS, QEMM (by QuarterDeck Office Systems Inc.). 5) In order to have a correct UTC time specification in your outgoing TICs, please note that you must have the environment variable "TZ" correctly set in config.sys (OS/2) or autoexec.bat (DOS). E.g. for Central European Time (CET): SET TZ=CET-01 (winter, "normal" solar time) SET TZ=CET-02 (summer, daylight saving time). E.g. for USA East Coast: SET TZ=EST5EDT Eastern time is 5h less than UTC and Daylight saving applies with the "standard rule" from the first sunday o april to the last sunday of october. More complicate expressions might be used to specify automatic change to and back from daylight saving, if a fixed rule is available. E.g. for Italy: daylight is 1h ahead from the last sunday of march to the last sunday of september. SET TZ=CET-01CDT,M3.5.0,M9.5.0 (See a C manual for further details). Command Line OPTIONS and SWITCHES To get help about the command line syntax, use the "-h" or "-?" command line switch: type "NEF -h" or "NEF -?". The following forms are available: NEF [<sw>] NEF [<sw>] NOTIFY [<adr> ...] NEF [<sw>] OUT|OUTVIEW [<file>] NEF [<sw>] CLEAN NEF [<sw>] HATCH|MATCH|CATCH|SEND NEF [<sw>] HATCH|MATCH|CATCH <name>[/<repl>] <TAG> [<desc>] [@DIZ] where: <sw> is one or more of: -c<cfg> Use <cfg> as configuration file instead of the default "Nef.Cfg". Example: "Nef -ce:\cfg\nef2.cfg" -d<adr> Hatch to <adr> only. If you Hatch/Catch/Match/Send a file with the -d<adr> command line switch, it is sent to <adr> only. <adr> can be any 4D address: in the case it is defined as a link in the matching "FileArea" or even only as a "FileLink", the specified akas, password and switches are applied. If, on the contrary, <adr> is a unknown address, the Hold flavour is used, no password is put in the TIC and the "from" aka is derived from an aka-match on the zone. Example: "Nef -d2:332/589 hatch" -h or -? Help. -k Keep local files (do not Replace, for Match/Catch). -l<log> Use <log> as logfile instead of the one specified via the "StatusLog <log>" configuration statement. Example: "Nef -le:\cfg\nef.log" -p Clean passthru areas before terminating, see also the "CLEAN" option. Examples: NEF -p NEF -p OUT -t Toggle Secure mode (see also the NoSecure cfg statement). A description of options follows: NOTIFY Notify linked areas to the specified address list, where <adr> is a 4D address. If no address is given or "ALL" is specified, NEF will notify to all defined links. OUT Outbound analysis (message output), optional concise output to <file> (no specification of each and every attached file). See the <OUT> and <OUTVIEW> "special tags" in the "Announce" section. OUTVIEW Same as OUT, but optional output to <file> is verbose. CLEAN Clean passthru areas. Since it might be not efficient to always scan the entire outbound to check for passthru files to be deleted, NEF must be explicitly instructed to do so (see also the "-p" command line switch). Example: "Nef Clean" HATCH Traditional hatch. MATCH Move file to destination area then hatch. CATCH Copy file to destination area then hatch. SEND (OS/2) Hatch via PM Dialog. If you use one of these hatch options, NEF will not process inbound .TICs; instead it will send the specified files to your links. Examples: "Nef Hatch" "Nef Match" "Nef Catch" "Nef Send" (OS/2 Only) When no parameters are specified after the hatch option, your interaction is required: you will be requested the filename specification (Dos or OS/2 wildcards allowed) and, for each matching file, the optional "replace" name, the area TAG, the description and the optional "Long Description". On the other hand, if you specify the hatch parameters on the command line, you cannot give a "Long Description" apart from that taken from the File_Id.Diz. HATCH sends the specified files; they are not moved and their description is not modified. MATCH moves the specified files to the directory that corresponds to the specified <TAG>, updates their descriptions (see "Description Handling" in Overall operation) and sends them as per normal hatch. If a <replace> file is specified, it is deleted with its associated description. CATCH is just like Match, but the files are copied instead of moved. (OS/2) SEND allows to specify all the hatch parameters via a user friendly PM Dialog. Please make sure the PmHatch.Exe file is in the PATH. In the case the PmHatch program terminates abnormally, the NEF program will wait for it indefinitely: you can terminate it using CTRL-C or CTRL-Break. See the "PmHatch" section below for further information. Parameters for Hatch/Match/Catch: <name> This is the full pathname of the files you want to H/M/Catch. You need to specify the full path even if you are hatching files that reside in the directory corresponding to <TAG>. O.S. wildcards are allowed. <replace> This is the optional name of the file to be replaced: if the receiving system has this feature enabled, a file named <replace> in the <TAG> area will be deleted while importing the new file. <TAG> This is the tag used for distributing an echo-file area. <desc> This is the "short" file description and must be enclosed between quotes '"'. In the case you need to include the '"' character in the description, just precede it with a backslash escape character: '\"'. If you want to take this description from the files.bbs, you can just specify "@BBS". Although NEF allows not to specify any <desc>, it is highly recommended that a "short" description is supplied, even when a "long" one is used. @DIZ This parameter allows to (optionally) take a "long" description from the File_Id.Diz contained in archive <name>. Please note that this is an additional OPTIONAL field, while <desc> should be MANDATORY (although NEF does not complain about a missing <desc>). Note: Please realize that the "short" and "long" descriptions are two separate and indipendent items. Short description: single line, "Desc" keyword in TIC files. Lond description: multiple lines, "Ldesc" keywords in TIC files. Examples: NEF Hatch d:\p\prg12.rar/prg11.rar COMMS "New comm prg" d:\p\prg12.rar is hatched (NOT moved) into the COMMS area; prg11.rar will be deleted on receiving systems. NEF Catch d:\p\prg12.rar/prg11.rar COMMS "New comm prg" d:\p\prg12.rar is copied to the directory corresponding to the COMMS file area and is hatched to the COMMS area. prg11.rar is deleted locally and will be deleted on receiving systems. NEF Match d:\p\prg12.rar COMMS "New comm prg" d:\p\prg12.rar is moved to the directory corresponding to the COMMS file area, it is hatched to the COMMS area, no replace information is put in the outgoing .TICs. NEF Send (OS/2) Invokes the PM dialog window. NEF Hatch d:\apbbs\nef999.rar APBBS @bbs d:\apbbs\nef999.rar is hatched into the APBBS area, taking the description from the files.bbs. NEF Hatch d:\apbbs\nef999.rar APBBS "Nef 9.99" @diz d:\apbbs\nef999.rar is hatched into the APBBS area, taking "Nef 9.99" as the "short" description and the File_Id.Diz (if present in the archive) as the "long" description. NEF Hatch d:\apbbs\nef999.rar APBBS @bbs @diz d:\apbbs\nef999.rar is hatched into the APBBS area, taking the "short" description from the files.bbs and the "long" description from the File_Id.Diz (if it is contained in the archive). NEF -d2:332/504.2 Hatch d:\apbbs\nef999.rar APBBS @bbs @diz Same as above, but the file is hatched to 2:332/504.2 only. NEF OUT An outbound analysis is performed, the results are reported via messages in the area(s) configured in Nef.Cfg (see the Announce statement). NEF OUT Out.Txt Same as above, but the output is also written to "Out.Txt" in "concise mode". NEF OUTVIEW Out.Txt Same as above but the file output is verbose. NEF -p OUT NEF will report the status of the outbound and clean the passthru areas. If you need to maintain passthru areas, this is the most efficient use, since NEF must scan the outbound once to make two different things ("clean passthru" and "outbound report"). NEF Notify NEF Notify All A notification message is sent to all the defined links, specifying the linked areas. NEF Notify 2:332/589 1:234/567 A notification message is sent to the specified links. PmHatch OS/2 Only: To invoke the PM hatch program you must type "NEF send". The PmHatch program is very simple and intuitive to use: see the following description. You can select the destination Area Tag via a drop-down list: just click with the mouse on the button at the right of the entry field. You have three radio buttons to select the "type" of hatch (normal, with Copy, with Move), just as you use Hatch/Catch/Match from the command line. You can choose the file to be hatched via a file dialog box: just click on the "Browse" push button on the right of the field. The file dialog starts from the directory corresponding to the selected Tag, but you can move to any drive or directory. You can also specify a "Replace" file via a file-dialog by clicking on the "Browse" push-button on the right of the "Repl" field. When doing Copy or Move, the files.bbs of the destination area is updated and the "replace" file (if specified) is deleted, just as if the file were tossed from the inbound. You can mark the "No Local Kill" checkbox to prevent NEF from deleting the "replace" file in the local area. You can load a "short description" (Desc) from the files.bbs, by clicking on the "FilesBbs" push-button. You can load a multi-line "long description" (Long Desc) from the File_Id.Diz inside the archive, from the Files.Bbs or from a specified file (Arc Diz, FilesBbs, File push-buttons respectively). If you do not have the "CompressCfg <filename>" statement in Nef.Cfg, the "Arc Diz" push-button will be disabled. Of course you can always fill-in or modify any field manually. Now look at the five push-buttons at the bottom of the hatch dialog: <OK>: to exit the dialog and hatch all the entered files. <Prev>: to visualize the previous hatch entry. <Next>: to create a new (empty) entry in order to hatch another file or to move to next entry if <Prev> has been used. <Copy>: to copy the visualized entry to the first free position, in order to hatch another file by modifying the current entry. <Cancel> or ESC: to cancel the current entry. ALT-F4 or "Close", to abort (cancel all the hatch entries). ERRORLEVELS 0 - File areas modified: Match or .TIC processed. 1 - File areas not modified: Hatch or NO .TIC processed. 2 - Help requested. 3 - Abnormal termination 4 - Configuration file not found. 5 - Invalid parameter on command line. 6 - No Outbound defined in cfg file. 7 - Disk Full. 8 - Out of Memory. 9 - Can't open Log file. 10 - Prefix or Suffix too long. 11 - User Input Error (interactive hatch/match). 12 - TimeOut waiting for concurrent NEF process to finish. 13 - Error while accessing .SAV file. 17 - FileBase Busy TimeOut. 250 - MsgApi: Init Error. 251 - MsgApi: Area Open Error. CFG REFERENCE Before analyzing the cfg keywords in detail, let's introduce the overall mechanism that is at the basis of NEF's file forwarding capabilities. Each area (defined via the FileArea keyword) can be mono-directional or bi-directional. In bidirectional areas every link can send files to us and we forward to everyone, unless those with a "receive-from" override. Monodirectional areas can be "receive from everyone" or "send to everyone". Obviously, at least one link must have an override in the opposite direction, unless we are the destination or origination of all the files. NEF uses the three flags 'I' (Input: we accept from), 'O' (Output: we send to) and '*' (bidirectional) to define the direction of an area or link. Each area has a direction, that can be overridden on a per-node basis by a global (in the FileLink statement) or local (in the FileArea statement, before the pertinent link address) direction override. In other words: each link has a direction that is defined in order of priority (from lowest to highest) by the area direction (I|O|* in FileArea), the global link override (in the FileLink statement), the local link override (before link address in the FileArea statement). It is recommended not to use the global link override when not really useful, so that the area definition statements remain clearly readable without the need to keep one eye on the FileLink statements. Usually the global link override is useful when you have an uplink for many areas. For example: if one day the uplink and one of the downlinks switch their role, you have to move the 'I' flag from one FileLink statement to the other with no need to change all the area definitions. The area direction definition is very useful to allow automatic linking via the Link Robot both to normal "Uplink to Downlinks" areas and to reverse "Downlinks to Uplink" areas (mostly used for "pre" areas to collect files and send them to the coordinator). As a matter of fact, in response to a link request, the Link Robot only adds the requesting address (with no flags) to the FileArea statement. So the real characteristics of the link depend on the Area direction and on the link flags (FileLink statement). Conventions - Items between square brackets (e.g. [<item>]) are optional. - Items separated by '|' are mutually exclusive (e.g. I|O|*). - The names of the various Keywords are NOT case sensitive. - The area TAGs are NOT case sensitive. Please be aware that old TIC processors might not be able to handle tags longer than 8 characters or containing dots. - <WTAG> is a "Wild TAG" specification: it can be a normal area TAG or contain wildcards in the "OS/2 style". Examples: "*LOC*" specifies all tags that contain "LOC". "FW???" specifies all tags that have up to three characters after "FW". - When a directory path is required, the trailing backslash '\' is optional. - The ';' character starts comments: any character following the ';' is ignored. Please note that configuration text strings (e.g. Subj, Origin) can contain the ';' character provided they are enclosed in quotes '"'. - The maximum length of configuration lines (including FileArea definitions) is 510 characters. - ... means that you can list further items of the same type. - Unless differently specified, addresses are standard 4D and MUST begin with the zone number (FileArea statements excluded). Please, note that the order of the configuration statements follows some logical rule. In order not to create confusion in the .cfg file and not to break some _necessary_ order relation, please follow the scheme proposed in the example NEF_*.CFG files and in this reference documentation. S Y S T E M RegKey <RegKey> Registered Users only: <RegKey> is the registration key and it is NOT case sensitive. Example: RegKey dfhyuwru6274623 Address <Address> You can use as many Address statements as you need for all of your AKAs. The first one specifies the "primary" address. <Address> is a standard 4D address specification. Example: Address 2:332/504.0 ; Primary Address Address 2:332/524.0 ; Second line aka Address 2:332/500.0 ; Hub aka Address 9:999/999.9 ; one more aka StatusLog <LogFile> <LogFile> is the name of the file where all the operations performed by NEF will be logged, following the "Binkley Style". In multitasking environments, please be sure to use a file that cannot be used by other processes at the same time. For example: if (in your system) NEF can be executed while Binkley is running, please use different log files. Multiple NEF processes using the same config file (and therefore the same <LogFile>) will have no problem since NEF does not begin operations until the previous launched instance (if it uses the same .cfg file) has finished. Should you not want the log file, you can comment this keyword out. Example: StatusLog d:\bbs\log\nef.log EchoTossLog <filename> When NEF writes announcements into echoareas defined with the "AreaTag" statement, it writes the corresponding TAGs (one per line) to <filename>. If you use the "MaxPrm" statement (or MAXIMUS environment variable), "EchoTossLog" is not necessary and becomes an override of the echotosslog specification found in the Maximus .PRM file. If you do not like this output, you can override with the NUL name: "EchoTossLog NUL". Example: EchoTossLog d:\bbs\squish\echotoss.log NetFile <InboundDir> You can specify as many NetFile statements as you need, one for each inbound directory where NEF must look for new .TIC files. <InboundDir> is the pathname of the inbound directory. Example: NetFile c:\file\net OutBound <RootPath> [<Zone>] The outbound directories are specified with the same method as in squish.cfg. <RootPath> should not have an extension. The first OutBound statement does not have the <Zone> field and specifies the directory where NEF will build file attaches for the zone of the primary address. Subsequent OutBound statements must have the <Zone> field (Decimal). File attaches for the specified <Zone> are built in <RootPath>.<###>, where <###> is a 3 digit extension representing the zone number (hexadecimal). File attaches for zones different from the primary one and not matching any <Zone> of the OutBound statements are built in <RootPath>.<###>, where <RootPath> is the one specified in the first OutBound statement and <###> is a 3 digit extension representing the hexadecimal zone number. Note: The "OutBound" statements MUST be preceded by the "Address" ones. Example: OutBound c:\out\fidonet OutBound c:\out\amiganet 39 OutBound c:\out\amiganet 40 FileAttaches will be built in: Primary zone -> c:\out\fidonet zone 39 -> c:\out\amiganet.027 zone 40 -> c:\out\amiganet.028 other zones -> c:\out\fidonet.<###> where <###> is the 3 digit hexadecimal representation of the zone number TicHold <TicDir> This specifies the directory that holds all the .TIC files addressed to downlinks until they are sent and erased. Example: TicHold c:\file\tichold BusyFlags This enables the Binkley-Style .BSY support. When attaching a file to a node, the presence of an appropriate .BSY file is checked; if it is present, some other process may be working on the same node, so NEF saves the attach info to a private <config>.SAV file (i.e. NEF.SAV when NEF.CFG is the config file). On subsequent runs, NEF will look for a <config>.SAV file and use the information in it to attempt again the creation of the file attaches. If the .BSY file is not found, it is created, the file attach is built, then the .BSY is erased. The name of the .BSY file is the same as a file attach to the same node: only the extension changes. Warning: The .BSY method has a nasty drawback: if the process that has created a .BSY file hangs or is shutdown abruptly, the .BSY file remains in its outbound directory, so that no other process will gain access to that node until somebody erases the .BSY file. It is advisable to delete *.BSY from the most used outbound directories at startup (in autoexec.bat (Dos) or startup.cmd (OS/2)). NoRaidBeforeHatch Skips the scanning of netmail before the execution of hatch commands. This might be useful to avoid delays with huge *.MSG areas. MsgSize <bytes> To specify the maximum size (in bytes) for a message generated by NEF (minimum 8KB, default 12KB). Usually a larger message size is useful to avoid too many messages in reports of filebone availability. Anyway, please be careful not to use a size larger than your downlinks can handle. Example: MsgSize 90000 TicAreaCfg <filename> This defines the name of the file that contains all the file area definitions. See the "FileArea" keyword below for a description of the syntax. This keyword is optional: if you omit it, you can define your file areas directly in the .cfg file, provided you put all the FileArea statements _after_ the FileLink ones, at the end of the .cfg file. For systems with few areas the one-file configuration is handy, for systems with many areas and links, the separate file solution is recommended. Please note that the TicAreaCfg file can contain FileArea statements and comments ONLY. Example: TicAreaCfg d:\bbs\nef\ticarea.cfg CompressCfg <filename> (OS2) To allow the extraction of File_Id.Diz while using the Pm Hatch. <filename> must specify the location and name of a "Squish style" compress definition file. In the case you are using a case-sensitive de/compression program (e.g. OS/2 ZIP/UNZIP), please make sure to use the correct switches in <filename>. If you are already using Squish and or Maximus, you can just specify the name of their compress.cfg (but do check that they indicate the necessary switches to avoid case sensitiveness during extraction). Refer to the "Compress Definition File" section at the end of this reference for the syntax of this configuration file. Example: CompressCfg c:\squish\compress.cfg Optional Squish Support SquishCfg <filename> It is used to specify the squish configuration file, so that NEF can automatically get the path, type (SDM vs Squish) and primary address for the announcement areas defined with the "AreaTag" statement. When SquishCfg is defined, if you use "AreaTag <Tag>" to define announcement areas, the "FromNode <adr>" statement is only used to override the primary address specified for that area in Squish.Cfg (including the -p<address> overrides). NEF supports the "Include" keyword of Squish.Cfg: just be sure to always use the full pathname in the Include statement if NEF and Squish run from different paths. Both echomail and netmail areas are recognized by their Squish tags. Netmail areas will have the Private attribute and no origin by default. Local overrides are still possible via local "Origin" and "Attr" statements. Example: SquishCfg c:\squish\squish.cfg Optional Maximus 3.xx Support MaxPrm <filename> If the MAXIMUS environment variable is defined, this statement is an optional override only. It is used to take the default for EchoTossLog and to get the name and location of the files necessary for filebase updating. The ".prm" extension in <filename> can be omitted. Example: MaxPrm d:\bbs\max\max.prm MaxAreaAdd <fileareactl> <lev[/keys]> <acs> [<division>] MaxAreaCompile <command> NEF is able to add new (created) areas to the Maximus filearea.ctl or equivalent. <fileareactl> is the fully qualified name of the Maximus file-area definition file. <lev[/keys]> protects areas of higher privilege from being automatically added to the Maximus configuration. The level and keys are to be compared to those of ProtArea statements and FileBone-format files. <acs> is the Maximus access string to be used in <fileareactl> for the new area. <division> is the optional specification of a division where you want to put new areas. If not specified or not found, the new areas will be appended at the end of <fileareactl>. <command> is an external command to be executed before NEF ends, from the Maximus system directory. It should be used to compile the new Maximus configuration via SILT/SILTP. The area name is taken equal to the area TAG, with dots changed to underscores. The area description is taken from the FileBone-format files if available, otherwise it is taken equal to the area TAG. Example: MaxAreaAdd d:\max\filearea.ctl 0 Transient Tic.New MaxAreaCompile siltp max -a -2a The new areas, will be inserted at the end of division "Tic.New" in the file "d:\max\filearea.ctl", with an access string of "Transient". Areas with protection level above 0 or any protection key will NOT be added to maximus configuration. Before terminating, NEF will invoke the SILTP compiler to update the area configuration. The command will be executed after changing the current directory to the Maximus system one (probably d:\max\). FileBaseUpdate Requires the MAXIMUS environment variable or the "MaxPrm" statement _before_ in the cfg. NEF will automatically update the filebase for all the areas changed when tossing/hatching new files. No more need to run external FBP (FB). Example: FileBaseUpdate UniqueDmpLine Makes NEF generate FILES.DMP filebase files with descriptions on one line only (multiple lines are concatenated). By default, NEF outputs multi-line descriptions without changes to FILES.DMP: when using L)ocate and N)ewfiles commands, Maximus will respect the original formatting, but the continuation lines will be aligned to the left. When this statement is used, the original formatting of descriptions is lost (in the filebase) but Maximus will be able to word-wrap and align when executing L)ocate or N)ewfiles commands. TIC Processing NoSecure Disables the secure mode. When "NoSecure" is used, NEF will toss incoming files ignoring errors due to missing password, password mismatch and missing from-authorization (sender not linked, sender receive only). You can also use the "-t" command line switch to toggle between Secure and NoSecure modes. Anyway the error will be noted in the logs and <BAD> message report (see Announce statement). Example: NoSecure NoReplace <WTAG> ... Multiple statements can be used. The specified <WTAG>s indicate in which areas you do not want NEF to delete files specified by the "Replaces" keyword in inbound TICs. Example: NoReplace * ; to avoid Replace in all areas CheckCRC This enables the CRC check of ingoing .TICs. If an ingoing .TIC has the CRC keyword, the specified CRC is checked against that of the relative file and an error is reported in case of mismatch. Outgoing .TICs will have the CRC only if it is present in the ingoing one. TICs originated by NEF (various Hatch modes) will always have the CRC keyword. Touch Ingoing files are "touched" while being moved to their destination directory (i.e. their timestamps are set to NOW, so that they will be seen as new files by all the utilities that use the file date-time to compute the age of files). (OS/2) When the files are touched in HPFS, the creation date is modified, not the modification one, in order to make the files recognized as new by Maximus and FLM (my File List Manager) without changing the date that is normally shown and transferred: you "see" and transfer to your downlinks the original date of the file while Maximus and FLM are able to realize that the file is new. (DOS & OS/2 FAT) Warning: The original file timestamp is lost and the downlinks will receive the forwarded files with the new timestamps. MultiLineDesc <nnn> [<c>] By default, files.bbs description must be on a single line; this statement enables Multi-Line support. <nnn> is the number of spaces that must precede the continuation lines. <c> is the continuation character. If <c> is NOT specified, it is assumed that the continuation lines must be preceded by <nnn> spaces. If <c> IS specified, it is assumed that the continuation lines must be preceded by <nnn> spaces, the <c> character and one more space. For example, to have the 2nd and following description lines in files.bbs start at the 32nd column, use: MultiLineDesc 31 A description in files.bbs would be like: Test.Zip This is the first description line this is the 2nd line this is the 3rd line ^ ^^ 1 31 32 To have the continuation lines preceded by a '|' character, use: MultiLineDesc 29 | A description in files.bbs would be like: Test.Zip This is the first description line | this is the 2nd line | this is the 3rd line ^ ^ ^ 1 29 32 NewAreasPath <path> NewAreasFrom <address> [-0] [#<aka>] [<path>] <path> is the base directory for new file areas automatically created by NEF on reception of .TICs with unknown area TAGs. <address> is a 4D address that must be enabled to automatically create new areas. -0 (zero) specifies that areas created by <address> must be PassThru. <aka> is the optional from-address to be used by NEF in outgoing .TICs for the areas automatically created by <address>. The <path> in "NewAreasFrom" is an override for the default specified in "NewAreasPath". Any number of NewAreasFrom statements can be used. While adding new areas, NEF will NOT re-order the existing ones, anyway it will respect an existing alphabetical order. Example: NewAreasPath c:\file NewAreasFrom 2:331/110 NewAreasFrom 9:1/1 #9:999/999.9 NewAreasFrom 9:2/2 -0 d:\fido\passthru\ Let's suppose we have received a .TIC for area NEWAREA, which is not currently defined: - if it is coming from an address different from 2:331/110, 9:1/1 and 9:2/2 -> an error is reported. - if it is coming from 2:331/110 -> a new area is created with path c:\file\NEWAREA. - if it is coming from 9:1/1 -> a new area is created with path c:\file\NEWAREA and it is configured so that NEF will use 9:999/999.9 (which must be an aka previously defined in an Address statement) as the from-address for outgoing .TICs. - if it is coming from 9:2/2 -> a passthru area is created with path d:\fido\passthru\NEWAREA. DescStart "<string>" <WTAG> [<WTAG> ...] This allows to add <string> at the head of files.bbs descriptions while tossing files from area TAGs that match one of the <WTAG> specifications. This statement is useful for people using download counters and/or maximus flags for free download. Example: DescStart "/bt [00] " 1* 2* This adds "/bt [00] " at the head of files.bbs descriptions while tossing files from areas whose TAG begins with '1' or '2'. TagFwd <OrgTag> <FwdTag> <FileSpec> [<FileSpec> ...] This allows to forward files from an area to another. <OrgTag> and <FwdTag> are area TAGs. <FileSpec> is a file specification that accepts the OS/2 style wildcards (?,*). All ingoing files of area <OrgTag> which match one of the <FileSpec>s are forwarded to area <FwdTag>. This way you can split or merge areas. Example: TagFwd 1-Comm Bbs AC*n prova.* TagFwd 1-Data bbs * TagFwd 1-DITO BBS * TagFwd 1-Comm BBO * TagFwd ISNMAIN POINTLST ptlist.* ptdoc.* Files AC*n and prova.* coming from area 1-Comm and all the files coming from 1-Data and 1-DITO are forwarded to area BBS. All the files from 1-COMM are also forwarded to area BBO. Files ptlist.* and ptdoc.* from area ISNMAIN are forwarded to area POINTLST. FeatureLoad <DllName> (OS/2) Loads a "Feature" DLL, to allow third party extensions to NEF. <DllName> can be a simple filename without extension (".DLL" implied) if the DLL is in the LibPath, otherwise a fully qualified filename (extension included) can be specified. Feature <cfgline> (OS/2) Allows to specify configuration statements that are to be parsed by the DLL loaded with the previous FeatureLoad. Note: Multiple FeatureLoad statements are allowed, in which case the Feature statements refer to the last loaded DLL. Example: FeatureLoad MyDll Feature CfgItem1 "This is Item 1" Feature CfgItem2 "This is Item 2" TIC Announcements Each announcement area is defined by a dedicated group of statements. Many of these statements can be used before the first announcement area definition to establish defaults to be used in all subsequent area definitions, thus avoiding the need to unnecessarily repeat common statements. Global Keywords === Statements that can be used before area definitions to set === defaults (please note that all these statements can be === overridden in each area definition). FromNode <address> This specifies the 4D address to be used as the from-address in the announcement messages: it is used in the header, in the Origin and in the MSGID. Usually, it should be your primary address. Example: FromNode 2:332/504.0 ToNode <address> This specifies the 4D address to be used as the to-address in the announcement messages: it is used in the header. Usually, for echo area announcements, it should be the same as in FromNode. Example: ToNode 2:332/504.0 From <name> This specifies the name to be used as the from-name in the announcement messages. Usually it should be the SysOp name. Example: From Alberto Pasquale To <name> This specifies the name to be used as the to-name in the announcement messages. Usually it should be "All". Example: To All Subj <subject> This specifies the string to be used as the subject in the announcement messages. Note: If the Subj text contains the ';' character, it MUST be enclosed in quotes '"', otherwise NEF will take the ';' as the start of a comment. Examples: Subj New Echo Files Subj "New files; OS/2 BBS" Attr [P][K][C|H|D|N|O] This specifies the attributes to be used in the announcement messages. Usually no special attribute is necessary, except for private announcements in the netmail area. The available attributes are: P -> Private K -> Kill/Sent C -> Crash H -> Hold D -> Direct (equivalent to "CH") N -> Normal (default) O -> Normal (default) The required attributes can be listed in any order and are not case sensitive. Examples: Attr ; no attributes Attr N ; no attributes (Normal flavour) Attr PK ; Private and Kill/Sent Attr PC ; Private and Crash Attr PDK ; Private, Direct, and Kill/Sent HighAsciiOk Grants permission for High Ascii codes (> 127) in file descriptions. Prefix <filename> This specifies the file containing the prefix text for announcement messages: it is put by NEF at the head of the message body, just before the real announcement lines. It should usually contain something like "New Echo Files Received:". Example: Prefix d:\bbs\nef\PREFIX.NEF Suffix <filename> This specifies the file containing the suffix text for announcement messages: it is put by NEF at the end of the message body, just before the tear-line and the Origin. It should usually contain something like "File Request open to everybody between 06:00 and 23:00 GMT". Example: Suffix d:\bbs\nef\SUFFIX.NEF Origin <origin> This specifies the text to be used as the Origin in announcement messages. NEF will add the required " * " at the head and the address at the end, truncating <origin> if necessary to fit the 79 character maximum length. To disable the Origin (e.g. in netmail area) use an empty origin string. Note: If the Origin text contains the ';' character, it MUST be enclosed in quotes '"', otherwise NEF will take the ';' as the start of a comment. Examples: Origin <ApWorks Modena I><Tel.+39-59-246112/3> Origin "ApWorks Modena I; +39-59-246112/3" Origin ; empty origin to disable origin generation Area Definition === All the preceding statements can be used both before === announcement area definitions (to set defaults) and inside === each definition to override the defaults. AreaTag <Tag> [<path> [-$]] AreaPath <path> [-$] One of these statements starts the definition of an announcement area. <Tag> is the area TAG, to be logged to EchoTossLog provided this is not a NetMail area. <path> is the directory for the *.MSG format or the full filename (no extension) for the Squish base. -$ specifies the use of the Squish format. AreaTag <Tag> This is the form to be generally used when SquishCfg is defined. NEF will look-up the <Tag> in SquishCfg to find the corresponding path, message-base type and primary address. A local "FromNode" statement can be used to override the primary address for the area (including -p<address> specifications) found in SquishCfg. If this is an EchoArea, its <Tag> will be output to the EchoTossLog whenever NEF writes to this area. If this is a NetArea, as a default, the Origin will not be used and the Private attribute will be set; you can override this with local "Origin" and "Attr" statements . AreaTag <Tag> <path> [-$] This is the form to be used for EchoMail areas when SquishCfg is not defined or you want to override its information AND you want <Tag> to be logged to EchoTossLog. AreaPath <path> [-$] This is the form to be used when SquishCfg is not defined AND you do not need to log a <Tag> to EchoTossLog (NetMail areas or no EchoTossLog defined). Notes: Any of the statements described above in this "Tic Announcements" section can be used after the AreaTag/AreaPath statement to override the defaults for this announcement area only. Please note that you can use different AreaTag/AreaPath definitions with the same message area Tag/Path, in order to announce different file areas in different messages but in the same message area. Examples: AreaTag OS2BBS AreaTag OS2BBS d:\bbs\mail\os2bbs -$ AreaPath d:\bbs\mail\net Announce <WTAG> [<WTAG> ...] NoAnnounce <WTAG> [<WTAG> ...] This defines the list of file areas to be announced in the current announcement message area (the one defined by the previous AreaTag/AreaPath statement). Multiple statements are allowed. All the TAGs that match one of the <WTAG>s in "Announce" and do not match any of the <WTAG>s in "NoAnnounce" are announced in the current area. Obviously you can omit the "NoAnnounce" statement if you do not need to exclude areas that have been included via the "Announce" statement. "Announce *" makes all the file areas announced. Special tags: The following "special tags" can be used in "Announce" or "NoAnnounce" statements as if they were normal area TAGs, but are not included in the "*" wildcard (i.e. "Announce *" does not make them announced). "<BAD>" is used to announce all the TICs that have been processed with some error. "<DEF>" is used to announce all the files that have not been announced elsewhere. A separate announcement is generated after all other announcements have been completed, even if "<DEF>" is listed together with other TAGs. "<OUT>" is used to make a concise outbound report when the OUT or OUTVIEW command line option is used. Subj, Prefix and Suffix are ignored. "<OUTVIEW>" is used to make a detailed outbound report when the OUT or OUTVIEW command line option is used. Subj, Prefix and Suffix are ignored. "<THRU>" represents all passthru areas. If you want to keep NEF from announcing files received in PassThru areas, just use "NoAnnounce <THRU>". Examples: Announce UTILNET SOFTDIST SDS* NoAnnounce SDSOTH <THRU> This announces the file areas with tag "UTILNET", "SOFTDIST" and all those whose TAG starts with "SDS" but not "SDSOTH" or passthru areas. Announce PRIVFILE <BAD> <DEF> This announces area "PRIVFILE" and all the TICs that have been processed with errors; at the end, in a separate message, it announces the files that have not been announced elsewhere. Announce SPECIAL <OUT> This announces the file area with tag "SPECIAL"; at the end, in a separate message, it creates a concise report of the outbound. Announce SPECIAL <OUTVIEW> This announces the file area with tag "SPECIAL"; at the end, in a separate message, it creates a verbose report of the outbound. Complete example of the announcement definition section, SquishCfg defined: ---------------------------------------------------------------- ; Defaults definition FromNode 2:332/504.0 ToNode 2:332/504.0 From Alberto Pasquale To All Subj New Echo Files Attr Prefix PREFIX.NEF Origin ApWorks Modena I (+39-59-246112/3) Suffix SUFFIX.NEF ; Announcement areas: each statement is local to the preceding ; AreaTag and overrides the default one. AreaTag APWORKS Announce APBBS* Prefix RelPre.NEF Subj New ApWorks files AreaTag OS2BBS Announce APBBS* NoAnnounce *DOS* Prefix RelPre.NEF Subj New APBBS files AreaTag NETMAIL Announce <OUTVIEW> <DEF> From NEF To Alberto Pasquale Subj Not Announced Elsewhere HighAsciiOk AreaTag NETMAIL Announce <BAD> From NEF To Alberto Pasquale ToNode 2:332/504.1 Subj Processed with Errors ---------------------------------------------------------------- Complete example of the announcement definition section, SquishCfg NOT defined: ---------------------------------------------------------------- ; Defaults definition FromNode 2:332/504.0 ToNode 2:332/504.0 From Alberto Pasquale To All Subj New Echo Files Attr Prefix PREFIX.NEF Origin <ApWorks Modena I><Tel.+39-59-246112/3> Suffix SUFFIX.NEF ; Announcement areas: each statement is local to the preceding ; AreaPath and overrides the default one. AreaTag SWN_332.500 d:\msg\swn -$ Announce UTILNET Subj UTILNET file news AreaTag SWN_332.500 d:\msg\swn -$ Announce FIDONEWS SDS* ECHO-* FTSC NEWSLETR SOFTDIST NoAnnounce ECHO-R* Subj SDS/NEWS file news AreaPath d:\msg\net -$ ; Netmail to the SysOp Announce NODE* POINTLST <BAD> <DEF> <OUTVIEW> From NEF To Alberto Pasquale ToNode 2:332/504.1 Subj Reserved file news Attr PK ; This must be private and kill/sent Origin ; No Origin for netmail ! ---------------------------------------------------------------- FileFix Link Robot It's the traditional "Raid" or "TicFix" function: it allows downlinks (but also special uplinks) to link/unlink file areas via a netmail message. The message should have the agreed password as the subject, possibly followed by some switch. The required password is that defined in the "FileLink" statement described below. The body of the message contains the commands. There can be several commands on a single line provided they are separated by blanks. Password, switches and commands are case insensitive. Switches that can be used in the subject, after the password, only the _first_ letter is required (and checked): -Help Help. -Query List all areas (linked and available). -Linked List linked areas. -Unlinked List unlinked areas. The commands available for the message body are: [+]<WTAG> Links all the areas whose TAG matches <WTAG>. The '+' character is optional (useful in the case <WTAG> starts with the '-' character). -<WTAG> Unlinks all the areas whose TAG matches <WTAG>. %Help same as -h %Query same as -q %List same as -q %Linked same as -l %Unlinked same as -u Example: From: John Doe of 2:332/580.0 To: Nef of 2:332/504.0 Subj: Secret -H ----------------------------- %Query 1* -1-COMM +2* -2-WINDOW --- The Help and Query commands are invoked, all areas whose tag begins with '1' are linked, area "1-COMM" is unlinked, all areas whose tag begins with '2' are linked and area "2-WINDOW" is unlinked. Notes: The actual order of command execution is based on the area definition order. NEF scans the defined areas from the first to the last one only once, applying for each area all the pertinent commands. If a link in a FileArea statement is not properly defined in a FileLink one, it is removed when the Link Robot re-writes that FileArea statement in execution of an Add or Delete command. While re-writing areas, the Link Robot will NOT re-order the links. However it will respect an existing order while adding new links. If Area aka overrides are used, they are reported by Area-List commands. AutoLink <name> The robot will answer to the messages addressed to one of the addresses defined in the "system" section and to one of the names defined in the AutoLink statements. You can use as many AutoLink statements as you need to define all the akas you like. If no AutoLink statement is used, then the Link Robot is disabled. Example: AutoLink NEF AutoLink Raid AutoLink TicFix NetMail <path> [-$] [-p<adr>] This defines a netmail area to be searched for messages addressed to the robot. You can use as many NetMail statements as you need. The optional -$ indicates a Squish format area. The optional "-p<adr>" specifies the primary (default) address for the area. When multiple NetMails are defined, NEF needs <adr> to choose (via zone matching) the right area where to write the messages addressed to the FileBone's "FileFix" robo t. Usually all but the first netmail statements should contain a primary address specification. Note: when a Squish base is used, a pointer to the last scanned message is stored in <path>.NEF, so that next scan will consider new messages only. Example: NetMail d:\msg\fidonet -$ ; default netmail area NetMail d:\msg\os2net -$ -p89:456/789 ; OS2Net netmail area KillReceived This keyword instructs NEF to kill messages addressed to the Link Robot after the execution of the contained commands. When commented out, the messages are marked as received instead of being erased. AreaDescWrap <indent> <right> The descriptions returned by the "FileFix" functions will be word-wrapped so that continuation lines start with <indent> spaces and do not exceed column <right>. Example: AreaDescWrap 25 79 HelpFile <filename> This keyword defines the file to be put into the Link Robot's answer in reply to a Help request. Usually this file contains instructions for using the Link Robot. Example: HelpFile d:\bbs\nef\NefHelp.Txt ProtArea <WTAG> <level>[/<keys>] This keyword allows to selectively protect areas from automatic linking. Unlinking is always possible. The protection scheme is based on the traditional combination of level and keys. <WTAG> specifies the TAG or group of TAGs to be protected. <level> is an integer number in the range 0-65535. <keys> is a subset of the following 32 element set: {12345678ABCDEFGHIJKLMNOPQRSTUVWX} These keys are case insensitive. When processing an area TAG, NEF scans the ProtArea statements from the first one to the last one: the first matching <WTAG> determines the protection level and keys. If no match is found, <level> is assumed to be the maximum and <keys> the full set of available keys, so that the area gains maximum protection. Usually it's convenient to override the default maximum protection so that you can list only a few special areas with their protection level and keys while letting all the others get a default NULL protection (automatic linking for everybody). To accomplish this result, you can use a "ProtArea * 0" as the last ProtArea statement. Please, note that the order of the ProtArea statements is _essential_, since they area scanned from the first one to the last one in search for a match between the TAG in examination and the <WTAG> of the ProtArea statements. Example: ProtArea PRIVATE 1000/12ABC ; Protected private area ProtArea 1* 100/P ; Areas starting with '1' ; are not for everybody. ProtArea * 0 ; The remaining areas are ; for everybody. FileBone Support NEF is able to use information distributed via the FileBone.Na and FileBone.No files. Many useful functions are allowed by the use of these files, so, even if you do not receive them from your uplink, you could evaluate the possibility of creating "FileBone-style" files on your own, just to store some information that can be retrieved by NEF. When FileBone-style files are used: - The Query command reports the areas available on the FileBone, in addition to those that are not linked to the downlink but already available on the local system. - Area descriptions can be returned by FileFix commands. - Level and Keys protect areas from "FileFix" linking. A node is entitled to add an area only if it has level and keys that match the requirements from BOTH the "ProtArea" statements in Nef.Cfg and the <lev>[/<keys>] specification in a FileBone format file (if available). - Requests for unlinked areas can be forwarded to the FileBone. The requests that have been forwarded to some uplink are stored in a file named after the configuration one, changing the extension to ".Fwd". Usually the configuration file is "Nef.Cfg", so the forwarded requests will be stored in "Nef.Fwd". The format is: <Tag> <Addr>, i.e. every line contains a Tag followed by the 4D Address of the downlink that made the request. When a new area is created, NEF looks into this file in order to find nodes to be added to the new "FileArea" definition. If a requested (and not yet defined) Tag is found in two or more FileBone files, the request is forwarded to the uplink defined in the first FileBone statement only. Don't mind if the Nef.Fwd file contains multiple entries for the same Tag. This can happen when multiple requests for the same area have been received. When the first file comes in and the area is created, all entries will be deleted while the link will be added once. FileBone <file> [<fm> <to> <toadr> <acc> [<pre>]] Multiple FileBone statements are allowed. <file> is the filename of the FileBone-style file. If you want to enable the forward of requests for new areas from your downlinks to your uplink(s), you must specify the following fields (to be enclosed between quotes when containing space) so that they can be used to write netmail messages to your uplink's FileFix: <fm> is the "from" name. <to> is the "to" name. <toadr> is the "to" 4D address. <acc> is a <level>[/keys] specification, to limit the access of downlinks to request forwards addressed to <toadr> for the areas described in <file>. <pre> is an optional string to be prefixed to the area Tags that are being requested. Examples: FileBone \bbs\FileBone.Na "John Doe" SysOp 2:332/1 0 The "\bbs\FileBone.Na" file is used by NEF, also for request forwards. When a downlink requests an area that is not currently defined in the NEF configuration (usually TicArea.Cfg) but is described in FileBone.Na, a netmail message is written by NEF from "John Doe" to "SysOp" of 2:332/1 using the appropriate "from address" aka and "subject" (password) as per the "FileLink" definition of 2:332/1. The body contains a list of the requested area Tags, one per line. No (<acc> = "0") protection is specified (any downlink has access to request forwards). FileBone \bbs\FB.SP "John Doe" SysOp 2:332/1 30/a + Only downlinks with level equal or above 30 and with the 'A' key have access to request forwards. The requested tags will be preceded by "+". If you need a space between the '+' and the tag, then you must specify a <pre> that contains a space, so you have to enclose it in quotes: FileBone \bbs\FB.SP "John Doe" SysOp 2:332/1 0 "+ " FileBone Format The format for the filebone style is: Area <Tag> <lev>[/<keys>] <flags> <desc> <Tag> is the TIC area Tag. The original filebone format allows 8 character maximum but NEF is not that limited. <lev> is the protection level of the area, for "FileFix" functions. The original format allows the range 0-4095 while NEF allows 0-65535. <keys> are a set of protection keys (1..8, A..X). Not available in the original FileBone format. <flags> is a combinaton of !.*& and possibly other characters. By default (no flags) the area is uni-directional, from the uplink to the defined downlinks. ! : Can be found at any Filebone Hub. . : Only on some Filebone Hubs. * : Any node can hatch into. & : Do not send to downlinks. Others : Private distribution. Examples: ! : normal area from the uplink to its downlinks, available on all Filebone Hubs. !*& : return channel from the downlinks to the uplink, available on all Filebone Hubs. .* : bidirectional area (any node can hatch into), available on some Filebone hubs only. <desc> is the description for the area. Example: Area APBBS 0 P ApWorks OS/2 BBS programs Area NODEDIFF 0/f ! FidoNet: Weekly NodeList Updates ForwardWildReq When a FileFix "Add" request contains wildcards, by default it is NOT forwarded to the filebone. This verb enables even this type of request forward. Link Definitions The FileLink statement is used to define a link, specifying its password, attributes and privileges. The FileArea statement is used to define a file area, specifying its type and the list of connected systems (that must be defined via FileLink statements). FileLink <address> <password> [#<address>] <flags> [<attr> [<level>[/<keys>] [<WTAG> ...]]] The parameters of this keyword have been represented on two lines because of space, but they MUST be listed on a unique line in the .cfg file. This keyword defines a file link; you must use a FileLink statement for each of your links (both downlinks and uplinks). <address> is the 4D address of the link. <password> is the case insensitive password to be used for all TIC exchanges and for the Link Robot function. NEF has no limit for the password length, anyway you should be aware that other similar programs might have limits, so check with your downlink/uplink before choosing a long password (8 characters should be OK for everyone). #<address> This optional field indicates a "from" 4D address to be used for the .TICs sent to this link (overrides the zone-match and is in turn overriden by the area override (see "FileArea")). <flags> This field is a (case insensitive) set of characters: <H|C|D|N|F>[<S|T>][<I|O|*>]. It can be 1 to 3 characters long: - The first flag is mandatory; it defines the flavour of the file-attaches that NEF will create for .TIC and associated files. Please note that this flag can be overridden on a per-area basis by prefixing the link address with a new flavour-flag in the FileArea statement. The available choices for this flag and the consequent file-attach extension follow: H -> .HLO (Hold) C -> .CLO (Crash) D -> .DLO (Direct) F -> .FLO (Normal) N -> .FLO (Normal) The 'N' flag is provided for "compatibility", but it's the same as 'F'. - The second flag is optional: it defines whether NEF must send a .TIC together with the file or not. S -> .TIC sent (default). T -> .TIC not sent. Usually the default is used (this flag can be omitted), but sometimes points like not receiving the .TIC file. Please note that this flag can be overridden on a per-area basis by prefixing the link address with a new flag in the FileArea statement. - The third flag is optional. It is provided for completeness and it is sometimes very handy, but it is recommended not to use it too often since its use might unnecessarily complicate the interpretation of the configuration. It defines whether this link has bidirectional access to file areas or not. This is an override to the "area direction" field of each FileArea definition. Please note that this flag can be overridden on a per-area basis by prefixing the link address with a new flag in the FileArea statement. I -> Only Input is allowed from this link. NEF will not send files. O -> Only output is allowed to this link. NEF will not accept files. * -> Bidirectional link. <attr> These are the (case insensitive) attributes for the Link Robot's netmail replies: K -> Kill/Sent C -> Crash H -> Hold D -> Direct (equivalent to "CH") N -> Normal (default) O -> Normal (default) The Private attribute is always implied. ATTENTION: you should usually use the 'H' attribute for file links that are not netmail links too. Otherwise the "Normal" flavoured netmail replies will be routed as per your routing configuration instead of being holded for the file link. <level> This is an integer number in the range 0-65535 and represents the access level to the Link Robot for this node. Defaults to 0. If it is greater or equal to the protection level of a certain file area, then this node can link the area via the Link Robot, provided it has the necessary keys. <keys> is a subset of the following 32 element set: {12345678ABCDEFGHIJKLMNOPQRSTUVWX} and represents the (case insensitive) access keys to the Link Robot for this node. If <keys> contains all the keys that protect a certain area, then the node can link the area via the Link Robot, provided it has a sufficient access level. <WTAG> The optional list of <WTAG>s specifies the area TAGs that must be automatically linked to this node when they are automatically created by NEF. New areas can be automatically created when unknown TAGs are found in ingoing .TICs (see "NewAreasFrom" above in this reference). You can make NEF automatically link the downlink to the areas that match the <WTAG> specification(s). Examples: - FileLink 2:332/593 pwd593 IN Node 2:332/593 has password "pwd503", is enabled to send .TICs to us ('I') and the file attaches addressed to it (if any) will be normal flavoured ('N'). Note that file attaches to this node will only be possible if a local area override will be used, since the 'I' flag instructs NEF to accept files from the node but not to send to it. Nothing is specified about the Link Robot's reply flags and access level and keys, so this node will be able to link only areas with protection level 0 and no keys; the Robot's reply will be normal flavoured. - FileLink 2:331/196.1 pwd1961 H NK 300/ab Node 2:331/196.1 has password "pwd1961", nothing is specified about link direction (it will depend on the "area direction" and local overrides), the file attaches will be Hold flavoured ('H'), the reply netmails will be normal flavoured ('N') and kill/sent ('K'), the access level is 300 and the access keys are a,b. - FileLink 2:332/1 pwd1 #2:332/500 H N 900/ab MI* *OS2* Node 2:332/1 has password "pwd1", all the TICs sent to this node will use the from-address 2:332/500 (provided there is no aka override at the "FileArea" level), the file attaches will be Hold flavoured ('H'), the netmail replies will be normal flavoured ('N'), the access level is 900 and the access keys a,b. New areas whose TAG begins with "MI" or contains "OS2" will be automatically linked when they are automatically created by NEF. FileArea <TAG> <path> I|O|* [#<address>] [-0] [[<flags>]<link> ...] This keyword defines an echo file area. If you have a small system, you can put the area definitions in the main configuration file (e.g. NEF.CFG). For systems with a large number of areas and links, it is recommended to use a separate file for the area definitions: see the "TicAreaCfg" keyword, formerly discussed in this documentation. ATTENTION: when using the "TicAreaCfg" separate file, you must put ALL the FileArea statements in that file. You are not allowed to put area definitions both in the main .cfg file and in the dedicated TicAreaCfg file at the same time ! Please note that all the FileArea statements, if included in the main .cfg file, MUST be defined _after_ the FileLink statements. <TAG> is the area TAG. <path> is the directory for the file area. I|O|* is the (case insensitive) "area direction" and defines the default direction for the area: 'I': we accept files from the listed nodes but do not send to them, unless an override flag is present before the <link> or in the pertinent "FileLink" definition. This should usually be used for "pre" areas, in which files must be collected from downlinks and sent to the area coordinator via the uplink, which will probably need a local 'O' override. 'O': we send files to the listed nodes but do not accept from them, unless an override flag is present before the <link> or in the pertinent "FileLink" definition. This should usually be used for areas that must be distributed to downlinks. The uplink will need a local 'I' override before its <link> field or a global one in its FileLink definition. '*': the area is bidirectional, so we both send and accept files to/from the listed nodes, unless an override flag is present before the <link> or in the pertinent "FileLink" definition. This should be used for bidirectional areas, in which everybody is allowed to "hatch" files. #<address>: defines the primary address to be used for this area; overrides both the default zone-match and the aka overrides in "FileLink" definitions -0: When the "-0" (zero) is specified, the area is "Passthru", that is its files will be deleted when already sent to all the downlinks. Please note that ANY file (apart from FILES.*) present in the <path> and not attached to any system will be deleted. NEF must be explicitly instructed to delete the old files in passthru areas, usually in some maintenance event. See also the "-p" and "CLEAN" command line options. The list of linked nodes follows; each node can have some <flags> attached before the node address. The available flags are the same as for the <flags> field in the "FileLink" statement. <flags> This is an optional (case insensitive) field made up of 1 to 3 characters: [H|C|D|N|F][S|T][I|O|*]. - The first flag defines the flavour of the file-attaches that NEF will create for .TIC and associated files. Please note that this flag overrides that in the pertinent "FileLink" statement. The available choices for this flag and the consequent file-attach extension follow: H -> .HLO (Hold) C -> .CLO (Crash) D -> .DLO (Direct) F -> .FLO (Normal) N -> .FLO (Normal) The 'N' flag is provided for "compatibility", but it's the same as 'F'. - The second flag defines whether NEF must send a .TIC together with the file or not. S -> .TIC sent. T -> .TIC not sent. Please note that this flag overrides that in the pertinent "FileLink" statement. - The third flag defines the direction of the link. Please note that this flag overrides that in the pertinent "FileLink" statement, which in turn overrides the "area direction". I -> Only Input is allowed from this link. NEF will not send files. O -> Only output is allowed to this link. NEF will not accept files. * -> Bidirectional link. <link> This is a 4D address, that can be abbreviated whenever the preceding address has the same zone, zone:net or zone:net/node. For the first <link>, if incomplete, the primary address for the area is used; anyway NEF always writes the first address in complete form when rewriting the area due to a Link Robot command. Examples: Please note that the situation might be a little different from what explained below, since the FileLink definitions could have some overriding flags. FileArea AREA1 d:\file\area1 O I2:332/1 504.1 .2 1:2/3 Typical area definition, where we receive from the uplink (marked with 'I') and forward to the listed downlinks (area direction 'O'). FileArea AREA2 d:\file\area2 O -0 I2:332/1 504.1 .2 1:2/3 Same as above, but passthru. FileArea AREA3 d:\file\area3 I O2:5/1 3/1 332/504.2 .3 This is a "reverse" area, where we receive from the listed nodes (area direction 'I') and send to the one marked with 'O'. FileArea AREA4 d:\file\area4 * 2:5/1 3/1 332/504.2 .3 This is a bidirectional area (direction '*'), where we receive from any of the listed nodes and forward to all the others. FileArea AREA5 d:\file\area5 O #2:332/500 I2:332/596 C555 A normal "up-link to down-links" area ('O'); we use 2:332/500 as the primary address, accept files from 2:332/596 and forward to 2:332/555 with a crash flavoured file attach. FileArea AREA6 d:\file\area6 O S2:332/504.1 10:10/0 *100/1 Normal "up-link to down-links" area ('O'); 10:100/1 is the only node enabled to send to us (bidirectional override '*'); we forward to 2:332/504.1 and 10:10/0. If we hatch files, we send to 10:100/1 too, since it is bidirectional. We send the .TIC accompanying files to 2:332/504.1 ('S') even if it had a 'T' flag in its FileLink definition. COMPRESS DEFINITION FILE The file specified in the CompressCfg statement is a sequence of Archive definition blocks, each one starting with "Archiver" and ending with "End Archiver". You can find an example in the Compress.Cfg file included in the NEF distribution pack. The order of the archive definition blocks within this file may be important: when trying to unpack a compressed file, the list of archivers is scanned in a reverse order. In the case of two archivers that use the same identification string (e.g. ARC and PAK), you must specify the archiver that can unpack both (PAK) after the other one (ARC). The compress.cfg file can be shared between DOS and OS/2 applications: the "DOS" and "OS2" keywords are available to distinguish between the commands to be used under DOS and OS/2. O.S. specific archivers or commands must be prefixed with the relevant keyword. IMPORTANT NOTE: The lines that begin with "DOS" or "OS2" are parsed by the corresponding version of NEF. If you need the OS/2 version to execute a DOS command, you MUST NOT use the DOS keyword: if you do, it will never parse that line; if you do not, ir will execute the DOS command "normally", provided you have installed OS/2's Dos support. See the examples below. Archiver <ARCname> Starts the Archive definition block. <ARCname> is the name used to identify this archiver. Example: Archiver ZIP Extension <ext> Specifies the default extension for the compressed files. Example: Extension ZIP Ident <ofs>,<ID> <ofs> is a decimal integer number representing the offset at which an archive identity marker <ID> must be present. Negative values can be used to indicate offsets from the END of a compressed file. -1 means "the last byte", -2 "the second last byte" and so on. <ID> is a series of hexadecimal figures which represent the bytes of the marker string that must be present at the specified offset of the archive file. Example: Ident 0,504b0304 ; "PK^c^d" Add <command> Specifies the command to add files to an archive. %a and %f are translated to the name of the archive and file to add. Example: Add zip -jk %a %f Extract <command> Specifies the command to extract files from an archive. %a and %f are translated to the name of the archive and file to extract. Example: Extract unzip -qqnjC %a %f View <command> This line is recognized and accepted for compatibility, but not used. End Archiver This statement is used to close a Archive definition. Examples Complete example 1 (you need OS/2 only): Archiver ZIP Extension ZIP Ident 0,504b0304 Add zip -jk %a %f Extract unzip -qqnjC %a %f View unzip -v %a End Archiver Complete example 2 (you need DOS only): Archiver ZIP Extension ZIP Ident 0,504b0304 Add pkzip -a %a %f Extract pkunzip -n %a %f View pkzip -v %a End Archiver Complete example 3 (you need both OS/2 and DOS): Archiver ZIP Extension ZIP Ident 0,504b0304 OS2 Add zip -jk %a %f DOS Add pkzip -a %a %f OS2 Extract unzip -qqnjC %a %f DOS Extract pkunzip -n %a %f OS2 View unzip -v %a DOS View pkzip -v %a End Archiver Complete example 4 (archiver to be used under DOS only): DOS Archiver ZOO DOS Extension ZOO DOS Ident 0,5a4f4f ; "ZOO" DOS Add zoo a: %a %f DOS Extract zoo e:O %a %f DOS View zoo v %a DOS End Archiver Complete example 5 (it's a DOS executable, to be used under DOS or OS/2 indifferently): Archiver ZOO Extension ZOO Ident 0,5a4f4f ; "ZOO" Add zoo a: %a %f Extract zoo e:O %a %f View zoo v %a End Archiver S H A R E W A R E If you like this program and continue using it, you should pay the author for his work, as per the ShareWare concept of distribution. Please see LICENSE.DOC and REGISTER.DOC for information. Thank you for your interest in ApWorks programs.